Developers of media processing applications strive to provide versatile media processing functionality that can process many types of media formats. However, this objective presents many challenges. For instance, the industry has developed different media processing technologies for processing different kinds of formats. Further, the industry may apply different functionality to process protected content compared to unprotected content. (Protected content refers to content that should be subjected to safeguards to prevent malicious access to the content.) Thus, media processing functionality which seeks to process different formats and types of content may need to integrate different technologies. This may be a problematic requirement, as the different technologies may apply greatly differing processing paradigms. For instance, different technologies may apply different paradigms to create and manage media processing pipelines. This problem is exacerbated in those cases in which an application is required to rapidly and gracefully transition from one processing paradigm to another, such as when the application processes a playlist containing content items having differing media formats and possibly different security levels associated with the content items.
One approach to providing a versatile media processing application is to add intelligence to the application which defines the manner in which the application interacts with different media processing pipelines and associated formats. For example, the developer of an application can include a first application module which is specifically tailored to interact with a first set of media formats, a second application module which is specifically tailored to interact with a second set of media formats, and so on. However, this approach is problematic because it complicates the application, essentially making it “top-heavy” by incorporating logic to deal with different media processing formats. This approach is also not very extensible, meaning that it cannot be gracefully modified to account for modifications to existing formats and media processing technologies, and/or the introduction of new formats and media processing technologies.
A particular difficultly arises in those technologies which permit a user to supply plug-in processing modules for use in a media processing pipeline. For example, Microsoft Corporation of Redmond, Wash. provides media processing technology which constructs a media processing pipeline (defining a “graph”) by combining various filters together to achieve a desired processing operation. Microsoft Corporation further provides functionality which allows a user to “plug” a custom presenter module into a rendering module used in this graph. The presenter module serves to process the media information in a prescribed manner for output to a target device or other destination. However, such a custom presenter module is traditionally designed to function in the context of one particular graph associated with one particular technology. This makes it difficult to meet the objective of versatility discussed above. This is because the custom presenter module might not work well in the context of another kind of graph associated with a different technology (meaning that the custom presenter module cannot be “plugged into” another kind of graph). The ad hoc approach to application development described above can address this solution by providing different presenter modules which can be plugged into different respective graphs. But as mentioned, this approach is not optimal, as it complicates the application and/or the custom presenter modules with additional logic. Moreover, this logic is not readily extensible to address changes in media processing technologies.
There is therefore an exemplary need for more satisfactory solutions for processing media information.